![lsblk が更新されないときに調べること](https://devio2023-media.developers.io/wp-content/uploads/2018/11/eyecatch_amazon-elastic-block-store_1200x630.jpeg)
lsblk が更新されないときに調べること
弊社のサービス クラスメソッドメンバーズ では、お客様の各種お問い合わせのサポートを行っています。お問い合わせ頂いている中からあるあるな感じの事例をご紹介したいと思います。
今回はLinux系OSのEBSのルートデバイスのボリューム拡張についてです。
おもむろにlsblk
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 8G 0 disk └─xvda1 202:1 0 8G 0 part /
例えば、マネジメントコンソール「ボリュームの変更」でサイズを 8G から 16GB に増やした場合・・・
通常は lsblk で disk のサイズの変化が確認でき、その後パーティションを拡張するコマンド(growpart等)、ファイルシステムを拡張するコマンド(resize2fs等) を実行する手順になるかと思います。
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 16G 0 disk └─xvda1 202:1 0 8G 0 part /
ところが、条件によっては以下のような事象が発生します。
事例1. growpart 実行しても part のサイズが変わらない
事例2. そもそも disk のサイズが変わらない
それぞれ疑うところと対処を書いていきます。
事例1. growpart 実行しても part のサイズが変わらない
疑うところ
dracut-modules-growroot がインストールされている?
対処
OS を再起動する
パーティション拡張のコマンドには以下のものがあります。
- cloud-init の growpart
- dracut の growroot
dracut の growroot が有効となっている場合、growpart ではなく OS 起動時に growroot によりパーティション拡張する挙動のようです。
以下は Marketplace の AMI を用いて作成した RHEL6.7 の例です。growpart と growroot 両方入っています。
$ yum list installed | grep cloud cloud-init.x86_64 0.7.5-3.el6 installed cloud-utils-growpart.noarch 0.27-13.el6 installed $ yum list installed | grep dracut dracut.noarch 004-388.el6 installed dracut-kernel.noarch 004-388.el6 installed dracut-modules-growroot.noarch 0.23-4.el6 installed
OS 再起動すると /var/log/boot.log に以下のようなメッセージが出力され、パーティションサイズも自動で変更されます。
growroot: CHANGED: disk=/dev/xvda partition=1: start=xxxxx old: size=xxxxx,end=xxxxx new: size=xxxxx,end=xxxxx
余談ですが、Amazon Linux 2 では cloud-init の growpart のみインストールされていますが、growpart コマンドを実行しなくても OS 再起動すると /var/log/cloud-init.log に以下のようなメッセージが出力され、パーティションサイズも自動で変更されます。これはルートデバイスボリュームのみの挙動で、他のボリュームでは growpart を手動実行する必要があります。
cc_growpart.py[INFO]: '/' resized: changed (/dev/xvda, 1) from 8587820544 to 17177755136
事例2. そもそも disk のサイズが変わらない
疑うところ
Elastic Volume に対応していない?
(Nitroの場合)カーネルバージョンが古い?
対処
ボリュームをデタッチしてアタッチする または インスタンスを再起動する
Elastic Volume 対応かどうかの調べ方は、下記の記事に詳細が載っています。
Elastic Volumes サポートの初期化 (必要な場合)
describe-instances コマンドを使い、以下の2点を調べます。この両方に該当する場合は Elastic Volumes 非対応のため対処が必要です。
・2016 年 11 月 1 日以前にインスタンスを起動した
・2016 年 11 月 1 日以前にインスタンスにボリュームをアタッチした
また、上記のチェックをクリアしたとしても、Nitroでカーネルが古い場合は対処が必要です。詳細は下記の記事をご参照ください。
Linux インスタンスの Amazon EBS および NVMe
Linux カーネル 4.2 以降を使用している場合は、NVMe EBS ボリュームのボリュームサイズを変更すると、自動的にインスタンスに反映されます。古い Linux カーネルの場合は、EBS ボリュームをデタッチしてアタッチするか、インスタンスを再起動してサイズ変更を反映させる必要があります。
まとめ
事例別にご紹介しましたが、結論としてはこれにつきます。
困ったときは再起動
以上です。